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(57) Abstract: This invention relates to a SIP and SDP protocols. The idea of the invention is to modify SDP descriptions included 

2? in SIP messages to facilitate transcoding. After receiving an INVITE message from a calling party, the SIP proxy negotiates with 
a transcoder for getting a list of codecs of the transcoder and their address information. The SIP proxy adds the codec list of the 
transcoder to the received SDP description in the invite message, and sends this way modified SDP description in an INVITE message 
£^ to a called party. After receiving the modified SDP, the called party selects codecs or a list of suitable codecs according to preferences 
in the modified SDP and its own preferences. 
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Transcoding arrangement in a session initiation 
Field of the Invention 

The invention relates to SIP (Session Initiation Protocol) and SDP 
5 (Session Description Protocol) protocols. SIP is used to establish multimedia 
sessions in IP networks, and SDP, which is carried in SIP messages, is used 
to describe and negotiate the characteristics of the session media (such as 
audio or video). The characteristics include e.g. the audio and video codecs 
to be used, and also their parameters. 

10 

Background of the Invention 

SIP is a signaling protocol that handles initiation, modification and 
termination of multimedia sessions among two or more parties. SIP is a pro- 
tocol created by IETF (Internet Engineering Task Force) for facilitating mul- 
15 timedia sessions (such as voice calls) over IP networks. It is a part of the 
multimedia conference architecture of IETF. 

SIP is a TCP/IP application layer protocol, in a same way as HTTP 
(Hypertext Transfer Protocol) and SMTP (Simple Mail Transfer Protocol). As 
other TCP/IP protocols, SIP is independent from the physical network struc- 
20 ture 

SIP is used to initiate multimedia sessions, but the protocol itself 
does not describe the characteristics of the medias used within the session. 
That is done by another protocol, SDP, which SIP merely carries as payload. 
IETF SIP specifications define the conventions for SDP usage within SIP. In 

25 addition 3GPP (Third Generation Partnership Project) has specified own 
conventions for SDP usage in SIP, which currently differ somewhat from 
IETF. The main difference is that according to the IETF the negotiation al- 
ways follows offer-answer model, where SDP is sent once for each direction, 
and the attributes can be unidirectional (i.e. e.g. different codecs in different 

30 directions). In 3GPP it is possible that a third SDP message in the direction of 
the first one (offer-answer-final offer) is sent, and attributes are usually bidi- 
rectional (i.e. e.g. the same codec in both directions a mandatory require- 
ment). 

The media attributes described and negotiated by SDP include 
35 media types (audio, video, text etc.), codecs and their characteristics and the 
transport addresses where media should be sent. For example audio and 
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video are usually transmitted over RTP, and for that payload type number, 
UDP port number and IP address are needed. SIP/SDP messages usually 
traverse several proxy elements (IP hosts) for routing and service control 
purposes, while the media itself is send directly between the two communi- 
5 eating endpoints (IP hosts) whenever possible. 

Figure 1 shows a simplified example of a network architecture, de- 
scribing signaling (SIP/SDP) and media streams (RTP) among network ele- 
ments. When subscriber A (8) wants to invite subscriber B (9) to create a 
session between them, the signaling (1) between A and B usually needs to 

10 traverse via at least one SIP proxy (21). The SIP proxy provides name reso- 
lution and user location among other things, and communicates (2) with 
subscriber B as well. After the necessary signaling information has been ex- 
changed between A, B and the SIP proxy, a media (3) path can be created 
between A and B. The path carries one or more media streams (such as 

15 video, voice). Each stream is preferably composed of RTP packets. As the 
media streams are sent directly from A to B (and vice versa), A and B need 
to support a common codec for each media to be able to understand each 
other. SDP is used to negotiate theses capabilities. 

However, if there is no common codec among the parties, 

20 transcoding of the streams is needed between A and B. The transcoding is 
performed by a transcoder (IP host) (7) somewhere in the network. A suitable 
codec has to be negotiated (4) between A and the transcoder, and between 
B and the transcoder. This also means that there is one RTP session (5) be- 
tween A and the transcoder, and another RTP session (6) between B and the 

25 transcoder. 

Figure 2 shows an example of a known solution of assigning a 
transcoder between two parties, A and B. The calling party A (8) sends an 
INVITE message (22) containing SDP toward the SIP proxy (21). SDP con- 
tains the list of the codecs supported by A for each media for this session. 

30 The SIP proxy forwards (23) INVITE with SDP unmodified toward the called 
party (B). If B does not support any of the codecs described in the SDP it re- 
ceives, it generates an error response toward the SIP proxy (24). When the 
SIP proxy receives the error response, it knows that a transcoder is needed 
and starts the process. It can put A party on hold (25), and send a new 

35 INVITE with SDP (27) containing transcoder address and codecs toward B. 
Naturally, A acknowledges (26) the hold. If B answers with 200 OK (28), a 
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new INVITE (29) can be sent toward A offering the transcoder address and 
codecs as well. Naturally, the SIP proxy acknowledges (210) the 200 OK 
message, and A sends a 200 (SDP A) message (211) to the SIP proxy, 
which acknowledges (212) it. As an end result, both A and B have media 
5 streams to transcoder negotiated, and both have a signaling relation to SJP 
proxy. 

The problem of this solution is that it generates an additional sig- 
naling roundtrip (the error response (24), and a new INVITE (29)), which- 
causes additional delay to the call setup. Especially in a wireless network en- 
10 vironment those kind of delays can be unacceptable. The goal of this inven- 
tion is to eliminate this problem. This is achieved in a way described in the 
claims. 

Summary of the Invention 

15 The invention is related to a situation where no common codec (or 

generally any required media feature) is supported by the two communicating 
endpoints, and thus a transcoder (or generally any translator function) needs 
to be assigned to the media path. The idea of the invention is to modify SDP 
messages in SIP proxy so that transcoder assignment becomes (practically) 

20 transparent to the endpoints. After receiving an INVITE message from a call- 
ing party, a SIP proxy negotiates with a transcoder for getting a list of codecs 
of the transcoder and their address information (this could have been done 
already in advance). The SIP proxy adds, i.e. inserts the codec list of the 
transcoder (only those codecs not already listed by the calling party) into the 

25 received SDP message (embedded in the INVITE message), and sends the 
extended SDP message in an INVITE message toward the called party. The 
added codecs are associated with the address of the transcoder instead of 
the calling party. After receiving the modified SDP, the called party selects 
codecs or a list of suitable codecs according to preferences in the modified 

30 SDP and its own preferences, and sends the selection of codecs back to the 
SIP proxy embedded in a suitable SIP response message. No error response 
is generated if the called party supports at least one of the codecs inserted 
either by the calling party OR the transcoder, For the called party there is in 
practice no difference between the codecs offered by the calling party or the 

35 transcoder, except that the former should be given higher preference. 
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When receiving the respose, the SIP proxy examines whether 
transcoding is needed or not (not needed if called party supports a codec 
supported by the calling party). If transcoding is not needed, the SIP proxy 
modifies the SDP message to look as a respose to the original SDP gener- 
5 ated by the calling party. When the calling party receives the message it does 
not notice that the SIP proxy has done any alterations to SDP whatsoever 
After that, session establishment and codec negotiation proceeds normally 
according to IETF and/or 3GPP specifications and the SIP proxy has no need 
to intervene in it anymore. 

10 If transcoding is needed (called party did not list any of the codecs 

originally offered by the calling party), the SIP proxy modifies SDP message 
in such a way that it proposes codecs that the transcoder (and of course the 
calling party as well) supports. Those codecs are associated with the address 
of the transcoder. After this the session establishment and codec negotiation 

15 continue according to normal IETF and/or 3GPP specifications. The only dif- 
ference is that there are actually two negotiations, one between the calling 
party and the SIP proxy, and another one between the SIP proxy and the 
called party. The situation is transparent to the endpoints, and no additional 
signaling compared to ordinary session setup is needed. 

20 

Brief Description of the Drawings 

In the following the invention is described in more detail by means 
of Figures 1 - 6 in the attached drawings where. 

25 Figure 1 illustrates a simplified example of a network architecture, describ- 
ing signaling and payload streams among elements of the net- 
work, 

Figure 2 shows an example of a known solution of assigning a transcoder 
between two parties, 

30 Figure 3 illustrates an example of initiation signal information between a 
calling party and a SIP proxy, and between a called party and the 
SIP proxy according to the invention when transcoding is not 
needed and the calling party selects final codecs, 
Figure 4 illustrates an example of initiation signal information between a 

35 calling party and a SIP proxy, and between a called party and the 
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SIP proxy according to the invention when transcoding is not 
needed and the called party selects final codecs, 
Figure 5 illustrates an example of initiation signal information between a 
calling party and a SIP proxy, and between a called party and the 
5 SIP proxy according to the invention when transcoding is needed 

and the calling party selects final codecs for it, and the SIP proxy 
selects final codecs for the called party, 
Figure 6 illustrates an example of initiation signal information between a 
calling party and a SIP proxy, and between a called party and the 
10 SIP proxy according to the invention when transcoding is needed 

and the called party selects final codecs for it, and the SIP proxy 
selects final codecs for the calling party. 



Detailed Description of the Invention 

15 Figure 3 shows an example of initiation signal information between 

a calling party (i.e an originating party element) and a SIP proxy (i.e. a third 
party element), and between the called party (i.e. a terminating party ele- 
ment), and the SIP proxy according to the invention when transcoding is not 
needed and the calling party selects final codecs, First, the calling party (8) 

20 sends an INVITE message INV!TE(SDP A) (31) to the SIP proxy (21). The 
message contains SDP description A, which comprises information of the 
codecs of the calling party. Let the SDP be: 

v=0 

25 o=sender 123447798 123447798 IN IP4 128.17.34.2 

t=0 0 

c = IN IP4 111.111.111.11 
m= audio 20000 RTP/AVP 0 8 
a=fid:1 

30 m= video 20001 RTP/AVP 98 

a= rtpmap: 98 L1 6/1 6000/2 
a=fid:1 



35 



where v describes a version of the SDP protocol, and o is the sender of the 
SDP message, containing the sender's username, session ID, a version 
number of this announcement, network type, address type, and address. The 
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fields of letter t describe the start and stop times for a session; c describes 
connection data, comprising a network type, address type, and connection 
address. The fields of letter m describe, a media type, a transport port, trans- 
port protocol, and media format. The letter a means an attribute description 
5 for the session. 

Let's look at descriptions c, m, and a closer. As mentioned, c de- 
scribes a connection, in this case the Internet network using the IP4 protocol 
at the address 111.111.111.11. m describes media, for example audio at port 
20000 using RTP audio-visual profile as a transport protocol, either a media 

10 format 0 or 8. The next a-rows after the m-row describe optional attributes of 
the media of m - for example fid:1 indicates to which logical session media m 
belongs. The rtpmap attribute is needed if a media format of m is dynamic - 
for example media format 98 is a dynamic type, which means that this type 
has to be defined to be a certain type of media format. For example, a= 

15 rtpmap: 98 L1 6/1 6000/2 means that media type 98 of m is 16 bit linear en- 
coded stereo audio sampled at 16 kHz. So, media formats describe which 
codecs should be used. 

After receiving SDP A the SIP proxy negotiates (32) with the 
transcoder (7) for getting a list of the transcoder's codecs. The SIP proxy ex- 

20 tends (34) SDP A with that list. Let the codecs of the transcoder, which are 
added to SDP A be: 

c = in IP4 111.112.222.11 
m= audio 30000 RTP/AVP 10 11 
25 a=fid:1 

m= audio 30001 RTP/AVP 3 
a= fid:1 

m= video 30002 RTP/AVP 31 
a= fid:1 

30 m= video 30003 RTP/AVP 32 

a= fid:1 

It should be noticed that the connection address of the transcoder 
and the port numbers for the media formats should be given, as is the identi- 
35 fication of the logical session as well. Hence, for the given example, the SDP 
is: 
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v=0 

o=sender 123447798 123447798 IN IP4 128.17.34.2 
t= 0 0 

c = IN IP4 111.111.111.11 
5 m= audio 20000 RTP/AVP 0 8 

a= fid:1 

m= video 20001 RTP/AVP 98 
a= rtpmap: 98 L 16/1 6000/2 
a= fid:1 
10 v=0 

o=transcoder 123447799 123447799 IN IP4 128.18.35.15 
t=0 0 

c = IN IP4 111.112.222.11 
m= audio 30000 RTP/AVP 10 11 
15 a=fid:1 

m= audio 30001 RTP/AVP 3 
a= fid:1 

m= video 30002 RTP/AVP 31 
a= fid:1 

20 m= video 30003 RTP/AVP 32 

a=fid:1 

It should be also noticed that if both the transcoder and the calling 
party support certain common codecs, these common codecs are not needed 
25 to be added to SDP A. The transcoder and the proxy anyway store those co- 
decs in case, later on in the session initiation sequence, transcoding is 
needed. 

The SIP proxy sends (35) the modified SDP description (SDP 
A+T) in the INVITE message to the called party (9), which selects (36) a list 
30 of suitable codecs according to preferences of SDP A+T and its own prefer- 
ences. After this the called party sends (37) its own list in a SDP description 
(SDP B list) in a 200 message to the SIP proxy. Let this SDP description be: 
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v=0 

o=receiver 123446655 123446655 IN IP4 128.12.30.4 
t=0 0 

c= IN IP4 222.222.222.22 
5 m= audio 40000 RTP/AVP 0 

a=fid:1 

m= audio 40001 RTP/AVP 8 
a=fid:1 

m= video 40004 RTP/AVP 98 
1 0 a= rtpmap: 98 L1 6/1 6000/2 

a= fid:1 

m= video 40005 RTP/AVP 31 
a= fid:1 

15 The SIP proxy examines (38) the message from the called party, 

and in this case the result of the examination is that transcoding is not 
needed - both the calling and called party support certain common codecs. In 
this case the media formats 0, 8, and 98. The SDP description, which is sent 
(39) to the calling party, contains the information of the common codecs - the 

20 media formats 0, 8, and the common dynamic type 98. 

The calling party selects (310) final codecs. In this case, the call- 
ing party may select either audio format 0 or 8 - let's say that the selection is 
0. Actually, there is no need to select a video format, since there is only one 
common format, but if there were more than one common codec, the selec- 

25 tion should be made. A final SDP description containing the selected codecs 
with connection and port addresses information is sent (311) as an acknowl- 
edgement message to the SIP proxy, which simply forwards (312) it to the 
called party. RTP streams (314) can be established between the calling and 
called party. 

30 It is worth mentioning that there can be more than one media for- 

mat, which can be selected for a media type, but one should always be se- 
lected. For example audio formats 0 and 8 can both be selected for forming 
audio streams, but only one stream is used at a time per media type. 

Figure 4 shows an example of initiation signal information between 

35 a calling party and a SIP proxy, and between a called party and the SIP 
proxy according to the invention when transcoding is not needed and the 
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called party selects final codecs, First, the calling party (8) sends an INVITE 
message INVITE(SDP A) (41) to the SIP proxy (21). The message contains 
SDP description A, which comprises information of the codecs of the calling 
party. Let the SDP be the same as in the example illustrated in Figure 3. 
5 After receiving SDP A the SIP proxy negotiate (42) with the 

transcoder (7) for getting a list of transcoder's codecs. The SIP proxy extends 
(43) SDP A with that list. Let the codecs of the transcoder, which are added 
to SDP A be the same as in the example illustrated in Figure 3. 

The SIP proxy sends (44) the modified SDP description SDP A+T 
10 in the INVITE message to the called party (9), which selects (45) suitable co- 
decs according to the preferences of SDP A+T and its own preferences. After 
this the called party sends (46) its own list in an SDP description to the SIP 
proxy. Let this SDP description to be: 

15 v=0 

o=receiver 123446655 123446655 IN IP4 128.12.30.4 
t=0 0 

c = IN IP4 222.222.222.22 
m= audio 40000 RTP/AVP 8 
20 a=fid:1 

m= video 40004 RTP/AVP 98 
a= rtpmap: 98 L1 6/1 6000/2 
a= fid:1 

25 The SIP proxy examines (47) the message from the called party, 

and in this case the result of the examination is that transcoding is not 
needed - both the calling and called party support certain common codecs. In 
this case the media formats 8 and common dynamic type 98. The SDP de- 
scription, which is sent (48) to the calling party, contains the information of 

30 these common and final codecs. After receiving the final SDP information, 
the calling party sends an acknowledge message back (49) to the SIP proxy, 
which forwards it to the called party. RTP streams (410) can be established 
between the calling and called party. 

Figure 5 shows an example of initiation signal information between 

35 a calling party and a SIP proxy, and between a called party and the SIP 
proxy according to the invention when transcoding is needed and the calling 
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party selects final codecs for the sessions between it and the SIP proxy, 
First, the calling party (8) sends an INVITE message INVITE(SDP A) (51) to 
the SIP proxy (21). The message contains SDP description A, which com- 
prises, information of the codecs of the calling party. Let the SDP be the same 
5 as in the example illustrated in Figure 3. 

After receiving SDP A the SIP proxy negotiates (52) with the 
transcoder (7) for getting a list of the transcoder's codecs. The SIP proxy ex- 
tends (53) SDP A with that list. Let the codecs of the transcoder, which are 
added to SDP A be the same as in the example illustrated in Figure 3. 
10 The SIP proxy sends (54) the modified SDP description SDP A+T 

in the INVITE message to the called party (9), which selects (55) a suitable 
list of codecs according to preferences of SDP A+T and its own preferences. 
After this the called party sends (56) its own list in an SDP description (in the 
200 message) to the SIP proxy. Let this SDP description to be: 

15 

v=0 

o=receiver 123446655 123446655 IN IP4 128.12.30.4 
t=0 0 

c = IN IP4 222.222.222.22 
20 m= audio 40000 RTP/AVP 3 

a= fid:1 

m= audio 40001 RTP/AVP 10 
a=fid:1 

m= video 40004 RTP/AVP 32 
25 a=fid:1 

m= video 40005 RTP/AVP 31 
a= fid:1 



The SIP proxy examines (57) the message from the called party, 
30 and in this case the result of the examination is that transcoding is needed. 
The SIP proxy notices that the streams using the codecs of the calling party 
must be directed to the transcoder - instead of the called party, and the 
streams using the codecs of the called party must be directed to the 
transcoder as well. The transcoder will perform the transformation between 
35 the codecs of the calling party and the called party during the session. So, 
instead of the codec information of the called party, the SIP proxy sends (58) 
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an SDP description with the codec information of the transcoder, knowing al- 
ready the codec supported by the cafling party. 

The calling party selects (59) final codecs for the session be- 
tween it and the transcoder. Let's assume that the transcoder supports all 
5 media formats of the calling party, so the calling party may select either audio 
format 0 or 8 - let's say that the selection is 8 (if only one audio format type is 
desired). Actually, there is no need to select a video format, since there is 
only one common format, but if there were more than one codec, the selec- 
tion should be made. 

10 A final SDP description for the session between the calling party 

and the transcoder, containing the selected codecs with connection and port 
addresses information is sent (510) in an acknowledgement message to the 
SIP proxy, which makes storing actions of these codecs (including reserving 
the codecs in the transcoder), negotiating with the transcoder (511). The SIP 

15 proxy also selects the final codecs - let's say media formats 10 and 31 - for 
the session between the called party and the transcoder, negotiating with the 
transcoder. The SIP proxy sends (512) the acknowledgement containing 
SDP description with this final codec information to the called party. 

RTP streams can be established between the calling party and the 

20 transcoder (514), and between the called party and the transcoder (515). 

Figure 6 shows an example of initiation signal information between 
a calling party and a SIP proxy, and between a called party and the SIP 
proxy according to the invention when transcoding is needed and the called 
party selects final codecs for the sessions between it and the SIP proxy. 

25 First, the calling party (8) sends an INVITE message INVITE(SDP A) (61) to 
the SIP proxy (21). The message contains SDP description A, which com- 
prises information of the codecs of the calling party. Let the SDP be the same 
as in the example illustrated in Figure 3. 

After receiving SDP A the SIP proxy negotiates (62) with the 

30 transcoder (7) for getting a list of the transcoder's codecs. The SIP proxy ex- 
tends (63) SDP A with that list. Let the codecs of the transcoder, which are 
added to SDP A be the same as in the example illustrated in Figure 3, 

The SIP proxy sends (64) the modified SDP description SDP A+T 
in the INVITE message to the called party (9), which selects (65) final codecs 

35 according to preferences of SDP A+T and its own preferences. After this the 
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called party sends (66) its own list in an SDP description in a 200 message 
to the SIP proxy. Let this SDP description to be: 

v=0 

5 o=receiver 123446655 123446655 IN IP4 128.12.30.4 

t=0 0 

c= IN IP4 222.222.222.22 
m= audio 40001 RTP/AVP 10 
a=fid:1 

10 m= video 40005 RTP/AVP 31 

a= fid:1 

The SIP proxy examines (67) the message from the called party, 
and in this case the result of the examination is that transcoding is needed. 

15 The SIP proxy notices that the streams using the codecs of the calling party 
must be directed to the transcoder - instead of the cafled party, and the 
streams using the codecs of the called party must be directed to the 
transcoder as well. The transcoder makes a transformation between the co- 
decs of the calling party and the called party. 

20 Since the called party has already selected final codecs - media 

formats 10 and 31 - for the session between it and the transcoder, the SIP 
proxy makes storing actions of these codecs, negotiating with the transcoder 
(67). The SIP proxy also selects the final codecs - let's say media formats 8 
and dynamic type 98 - for the session between the calling party and the 

25 transcoder, negotiating with the transcoder. The SIP proxy sends (68) an 
SDP description with this final codec information in the 200 message to the 
called party. 

After receiving the final SDP information, the calling party sends 
an acknowledge message back (69) to the SIP proxy, which forwards it to the 
30 calling party. RTP streams can be established between the calling party and 
the transcoder (610), and between the called party and the transcoder (611). 

Figures 3 to 6 also illustrate the inventive method. The codec list 
of the calling party is extended by the codec list of the transcoder (not with 
the common codecs to the calling party and transcoder). This way a modified 
35 (extended) codec list is sent to the called party. The called party selects at 
least one final codec or a list of suitable codecs. The codec selection of the 
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called party is sent back to the SIP proxy, which examines whether transcod- 
ing is needed or not The SIP proxy also performs other, possibly needed, 
actions in this phase. As a response to the examination, the SIP proxy sends 
a suitable SDP description to the calling party. If needed, the calling party 
5 makes a selection of at least one final codec, and sends a final SDP descrip- 
tion back to the SIP proxy (otherwise the calling party acknowledges the re- 
ceived codecs). As a response to this final SDP description the SIP proxy 
performs necessary actions, such as sending a final SDP description to the 
called party. The inventive method is performed by the means of inventive 

10 arrangement 

As can be seen from Figures 3 to 6, the invention supports both 2- 
way and 3-way codec negotiation. Figures 3 and 5 show examples of 3-way 
negotiations, i.e. SDP descriptions are sent between parties (and a SIP 
proxy) 3 times. Figures 4 and 6 shows examples of 2-way negotiations, i.e. 

15 SDP descriptions are sent between parties (and a SIP proxy) 2 times. So, the 
inventive arrangement supports different terminal types. 

As a conclusion for the support of different terminals, the invention 
makes it possible to use 3G terminals as well. It should be mentioned that 
although the examples above use basic SIP methods for transporting mes- 

20 sages, being SDP a payload inside a SIP message, the messages can also 
be transported by using other methods, such as a PRACK method that is 
more compatible in many 3G cases. Also the description protocol does not 
have to be SDP, but it can be another suitable protocol. 

The invention also makes it possible to run a SIP proxy with less 

25 processing power. When a known SIP proxy works like a UAS (User Agent 
Server) to the calling party of a session and UAC (User Agent Client) to the 
called party, the inventive SIP proxy works more like an intermediator - not 
like a terminating end (UAS) or originating end (UAC). The intermediator 
needs less resource in the state-machine of the SIP proxy than an implemen- 

30 tation using agents. The intermediator function can be achieved according to 
the invention when the first SDP message from the SIP proxy to the called 
party is modified - offering the called party (and the SIP proxy as well) two 
counterpart addresses for initiating the logical session between the calling 
and called party. 

35 As can be seen, the invention can be implemented in many ways. 

Although, session initiation signals are described in this context using SIP 
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and SDP, it is clear that other protocols can be used. The invention can also 
be used in multicast solutions. Instead of a SIP proxy as a third party ele- 
ment, a CSCF (Call State Control Function) element can be used. Thus, it is 
evident that the invention is not restricted to the solutions described in this 
5 text, but the invention can be used in other solutions as well, in the scope of 
the inventive idea. 
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CLAIMS: 

1. A method for initiating a communication session between an originating 
and a terminating party in which description messages are sent between the 
parties via a third party, the initiating method comprising the following steps: 

receiving at the third party an invitation description message comprising a 
list of communication equipment supported by the originating party, 

modifying at the third party the invitation description message by adding to 
the list communication equipment supported by translation circuitry that 
negotiates with the third party; 

selecting at the terminating party at least one of the communication 
equipment in the modified message which is sent in a further description 
message to the third party; and 

identifying at the third party from said selection whether the translation 
circuitry is needed for establishing said communication session between the 
originating and terminating parties. 

2. A method according to claim 1 , wherein said step of selecting at the 
terminating party is carried out according to the preferences of the modified 
invitation description message and the preferences of the terminating party. 

3. A method according to claim 1 or 2, wherein if the translation circuitry is 
not needed, the following steps are performed: 

sending a description message to the originating party with the proposals 
of communication equipment common to both the originating and terminating 
party; 

choosing at the originating party from the proposals which of the common 
communication equipment is to be used in the established communication 
session; and 

acknowledging said choice by sending a final description message from 
the originating party to the third party which is forwarded to the terminating party. 
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4. A method according to claim 1 or 2, wherein if the translation circuitry is 
needed, the following steps are performed at the third party: 

sending a description message to the originating party with proposals of 
5 communication equipment supported by the translation circuitry; 

receiving an acknowledgment description message from the originating 
party with a final choice as to which communication equipment is to be used for 
the established communication session between the originating party and the 
translation circuitry; and 
10 storing the final choice of communication equipment to be used between 

the originating party and the translation circuitry in the established 
communication session; 

choosing from the description message sent during the selecting step, the 
final communication equipment to be used between the translation circuitry and 
15 the terminating party in the established communication session and forwarding 
said final choice to the terminating party in a final acknowledgment message. 

5. A method according to any preceding claim, wherein said terminating 
party is capable of selecting a plurality of suitable communication equipment in 

20 the modified message. 

6. A method according to claim 1 , wherein said step of selecting at the 
terminating party comprises making a final choice as to which communication 
equipment is to be used for the established communication session between the 

25 translation circuitry and the terminating party. 

7. A method according to claim 6, wherein if the translation circuitry is not 
needed the following steps are performed: 

sending said chosen communication equipment in a further description 
30 message to the originating party; and 
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acknowledging said choice by sending a final description message from 
the originating party to the third party which is forwarded to the terminating party. 

8. A method according to claim 6, wherein if the translation circuitry is 
5 needed the following steps are performed at the third party: 

storing said chosen communication equipment for the established 
communication session between the translation circuitry and the terminating 
party; 

choosing which communication equipment is to be used for the 
10 established communication session between the originating party and the 
translation circuitry and sending said choice to the originating party; 

receiving an acknowledgment description message from the originating 
party and forwarding said acknowledgment message to the terminating party. 

15 9. A method according to any preceding claim, wherein the communication 
equipment is a codec. 

10. A method according to any preceding claim, wherein the translation 
circuitry is a transcoder. 

20 

11. A method according to any preceding claim, wherein said established 
communication session is comprised of real time protocol (RTP) streams 
between the originating and terminating parties. 

25 12. A method according to any preceding claim, wherein said initiating 
communication session is performed by a signaling protocol. 

13. A method according to any preceding claim, wherein said initiating 
communication session is performed by a session initiation protocol (SIP) and 
30 wherein said description messages use a session description protocol (SDP). 
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14. A method according to any preceding claim, wherein said third party is a 
SIP proxy server. 

15. A method according to any preceding claim, wherein said third party is a 
5 call state control function (CSCF) element. 

16. A method according to any preceding claim, wherein the third party 
negotiates with the communication translation circuitry and is able to reserve 
communication equipment of said translation circuitry for use during the 

10 established communication session. 

17. A communication system for initiating a communication session between 
an originating and a terminating party, the system comprising: 

means for sending at the originating party an invitation description 
15 message to a third party comprising a list of communication equipment supported 
by the originating party; 

means for modifying at the third party the invitation description message 
by adding to the list communication equipment supported by a translation circuit 
that is able to negotiate with the third party; 
20 means for selecting at the terminating party at least one of the 

communication equipment in the modified message, the selection being sent in a 
further description message to the third party; and 

means for identifying at the third party from said selection whether the 
translation circuitry is needed for establishing a communication session between 
25 the originating and terminating parties. 

18. An originating device for communicating with a terminating device, the 
devices communicating via a third device in an initiating communication session, 
the originating device comprising: 

30 communication equipment for transferring data during an established 

communication session; 
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circuitry for sending an invitation description message to the third device 
comprising a list of the communication equipment supported by the originating 
party, wherein the invitation description message is modified by the third device 
by adding to the list communication equipment supported by a translation device 
5 that negotiates with the third device, wherein said terminating device selects at 
least one of the communication equipment in the modified message which is sent 
in a further description message to the third device for identifying from said 
selection whether the translation device is needed for an established 
communication session between the originating and terminating devices; 
10 circuitry for receiving a list of communication equipment supported by the 

other devices; and 

circuitry for sending acknowledgement messages. 

19. The originating device of claim 18, comprising circuitry for making the final 
15 choice of communication equipment to be used in the established communication 

session between the originating device and the translation device. 

20. A third party device located between an originating device and a 
terminating device for use in initiating a communication session, the third party 

20 device comprising: 

circuitry for negotiating with translation circuitry having communication 
equipment; 

circuitry for receiving from the originating device an invitation description 
message comprising a list of communication equipment supported by the 
25 originating device; 

circuitry for modifying the invitation description message by adding to the 
list, communication equipment supported by the translation circuitry; 

circuitry for sending said modified message to the terminating device 
which selects at least one communication equipment in the modified message; 
30 circuitry for receiving said selection; and 
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circuitry for identifying from said selection whether the translation circuitry 
is needed for establishing a communication session between the originating and 
terminating devices. 

5 21 . A terminating device for communicating with an originating device in an 
established communication session, the devices communicating in an initiating 
communication session via a third device, the terminating device comprising: 
communication equipment for transferring data during an established 
communication session; 
10 circuitry for receiving a modified invitation description message from the 

third device comprising a list of the communication equipment supported by the 
originating party and which has been modified by adding to the list 
communication equipment supported by a translation device that negotiates with 
the third device; 

15 circuitry for selecting at least one of the communication equipment in the 

modified message; 

circuitry for sending said selection in a further description message to the 
third device for identifying from said selection whether the translation device is 
needed for establishing said communication session between the originating and 
20 terminating parties; and 

circuitry for receiving acknowledgment messages. 

22. The terminating device of claim 21 , wherein the circuitry for receiving 
acknowledgment messages comprises circuitry for receiving the final choice of 

25 communication equipment to be used in the established communication session 
between the translation device and the terminating device. 

23. The terminating device of claim 21 , wherein the circuitry for selecting is 
able to make a final choice of communication equipment to be used in the 

30 established communication session between the translation device and the 
terminating device. 
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